Greetings!

You rang?

Still no word on the 80s yet...

This means that if you've got more than 10,901 tracks on your player (which is not at all out of the question for a grzelakian, sorry gargantuan, player)

I have an 80gb player that's not even full with more tracks than that.

And I always thought that playlists worked like a typical jukebox. When several people choose the same song, it will only be played once. Of course the jukebox won't tell you this and still keep your money.

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

No, I believe it leaves the rest of the playlist untouched.

But Peter was also refering to the fact that most people's playlists that reference the same song from different playlists, like a classical playlist and a mellow playlist would likely overlap to some extent.

So when I insert an album into my 'play everything' playlist, or use the 'same artist' thingy on the remote, it won't pull those songs out of the regular running order?

When you insert an album (whether from the search screen or the playlists menu), those tracks are added to the playlist, even if they were there already (even in shuffle mode). When you use the same artist thingy on the remote, those songs are swapped into position from wherever they are in the playlist -- it won't find songs by the same artist that aren't in the current playlist.

Peter

Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?

Current position is in the flash savearea, stored as a 32-bit FID. Dunno about position within that FID.

-ml

Anyone else have any ideas?

Current position has to be stored somewhere. I was wondering if maybe the current Fid was used to index the running order, but I realised that would 'fail' on duplicates. However, I also remembered that duplicates are quirky anyway - they always get removed during shuffle, and re-inserted during unshuffle, so I checked...

If you have 1 track duplicated in a playlist, and the player is playing one of them at the point of shutdown, it will continue to play the correct one after power up.

The search continues...

And how about total length of the running order? That has to be stored somewhere too, unless the player counts them every time it boots up...

Edit: Length = number of songs, in this context.

Hmm...that depends. If the player keeps the whole running list in memory then it'd be trivial to either count each entry during load, or if being loaded as an array, to do a sizeof() and do the math after loading.

But if the player only loads as much of the running list as it needs then it would need to be stored.

I suspect that since the entire database is kept in memory then the whole running list is too.

Peter, can you clue me in as to where I might look to get the current running order position, and the total number of tracks in the current running order? Like, when the Track:Info screen says:

[310/6521]

Are these values only in memory or are they in the flash savearea? Or somewhere else where one can read them?

The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

The header also contains a running-order index and a timecode in centiseconds -- but these are only used for bookmarks; the running-order index and timecode for the current running order are stored to flash, not disk (so they can be written with the last dying milliamps if the player is yanked).

Mark's observation, that sector 0 contains a partial copy of the programme and/or running order, is due only to buffer reuse and is not significant.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

Peter

This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...

The first sector of each stored running-order (i.e. sector 0 for the current running order and sectors 512, 1024, and 1536 for the three bookmarks) contains a header structure that includes, among other things, the sizes of the programme and running order, the repeat mode, and the FID of the playlist used to form the current running order (or 0 if it's "custom" i.e. was made from search results or if inserts or appends were done to it).

I don't suppose that header structure is in a .h file somewhere like the other dynamic data stuff is? (Just so you know, I really do plan on using this stuff, I'm not just asking out of idle curiosity.) I can possibly reverse-engineer portions of it, but if it was in emptool somewhere or you had it handy, that'd be of great help to what I'm doing.

The usual caveat applies: that all this will pass, like rain on the mountain, like a wind in the meadow, after 2.0final comes out.

That's fine, I'll be happy to bug you again for the new format when that happens. Semantic question, though... Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

This sounds like information that the The "Developer Info" gnomes should be collecting and re-posting...

Well it sounds like the shelf life of this info might not be all that long... I'm going to hold off on posting this one until I can figure out some more details of what the bits and bytes all mean.

Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0 final will be the last release with this format. Releases beyond 2.0 will probably have a different format.

Does "after 2.0 final comes out" mean that 2.0 final will have a different format, or that the future releases beyond 2.0 will have a different format?

2.0final will have the same format, unless some sudden and desparate bug requires that we change it, which is very unlikely. The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Peter

The format isn't in an emptool source release, but it shouldn't be too hard to work out, at least for reading. There isn't even a CRC.

Thanks guys, at least I know where to look now, I shouldn't have any problems deciphering it.

Go for it, Tony!

But we must all be careful not to be disappointed a year from now when we may be playing with v3-beta player software, and discover that (1) the format is entirely different, and (2) they (peter) cannot tell us anything about the new layout. I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Cheers!

I fully expect this to be the case, as the data layout on disk is one of the "tricks" they will have evolved, and will not want to share with any competitors.

You really think that's the case? I'm not sure that on an EOL product, the layout of particular bits of information is all that much of a trade secret. I could be wrong, maybe they're sharing the same data structures with other living products... But I've found that, while the guys aren't spending their time advertising the formats or publishing them, they've been very helpful in casually pointing at a given area and saying "reverse engineer away, young man."

So, by all means, we should take advantage of any knowledge of the current layout, and just plan on having to do it "the hard way" when it all gets pulled out from under us.

Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?

Fellas, is Mark correct? Do you anticipate having to be more guarded about stuff like this in the v3 timeframe due to similarity to other products?

The running order can be used to work out which songs you've listened to and which you haven't. Legally, that information is the copyright property of the record company.

No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Peter

No, actually I'm kidding. There are some specific things we feel nervous about helping people reverse-engineer, and I'm not going to be drawn on what they are, but hitherto this certainly hasn't been one of them.

Huzzah!

There are some specific things we feel nervous about helping people reverse-engineer

<cough>tuner settings</cough>

I'd guess it would be stuff about the serial number and other things. <paranoia>Or the secret mind control system that makes you want to go out and buy more empeg/SB stuff...</paranoia>

- Trevor

Go for it, Tony!

I got it!

I haven't worked out all the fields of the header in the first sector of hda3, but I found the fields I care about for my purposes. Here's what I've got (duplicating your previous information just for clarity)

0x0010:  playlist size (PS) 

0x0018:  running order size (ROS)

0x0200:  beginning of FIDs in the playlist, 8 bytes each

0x0200 + 8 * (PS):  beginning of the running order indexes, 4 bytes each

.
The ROS is only different than the PS if you've shuffled (due to duplicate removal.)

So with the above information, given an index into the current running order, I can find the FID number associated with that index. That's not very interesting for the currently playing FID, because we can get that from many areas, including the flash savearea and /proc/empeg_notify. BUT.. Cobbling this information together allows me to get the NEXT fid that will play in the current running order. If I'm at index N of the running order, I just need to go to index N+1, follow that as an index into the FIDs area at 0x200, and there we have it. I wrote a tiny C program to convert a running order index into a FID and it is working flawlessly. Righteous!

Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.

Sweet, now I can finally go back to working on my school projects...

Now all I need is a way to get where we're at within the current running order from the userland... It's in the flash savearea, but there's no ioctl() for that. If there was, well, my master plan is going to start coming together very nicely.

I guess if Mark doesn't do something I'll write a patch.

The savearea is readable from /dev/empeg_state. The stock kernel doesn't allow multiple readers in there at once though, so Hijack v314 will be out shortly with that capability added.

Cheers

Woohoo!

Ok, so I'll find something more useful to do.

I sent a patch to Jan for gpsapp which implements real time display of NMEA strings, but I'm not overly happy with it. He hasn't commented yet so either he's busy or he isn't either

I was going to try something with raster underlays for the gpsapp route screen, and worked out a way to color-reduce a geotiff using the USGS colormap standard to something which would display what I considered "interesting" information and punt the rest, and then actually thought to crop a 128x32 section and noticed it just wasn't large enough until I went to 4x zoom out.

Maybe I should play with trying to figure out saved tuner settings some more.

Yeah, I've been kind of busy this week, so I haven't had a chance to look at the patch. btw. Why is is useful to see realtime NMEA strings? If it is to check whether the gps -> empeg connection is working, perhaps having something simple like a virtual flashing led that toggles whenever we've received serial input, and possibly flashes with a brighter color when we've actually been able to interpret this input. That would be more generic as it is applicable to the non-NMEA protocols as well.